Adding fvdb-core by swahtz · Pull Request #31550 · conda-forge/staged-recipes

swahtz · 2025-11-25T02:10:34Z

Checklist

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

github-actions · 2025-11-25T02:11:57Z

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

conda-forge-admin · 2025-11-25T02:12:39Z

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found some lint.

Here's what I've got...

For recipes/fvdb-core/meta.yaml:

❌ This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler.

For recipes/fvdb-core/meta.yaml:

ℹ️ Please depend on pytorch directly. If your package definitely requires the CUDA version, please depend on pytorch =*=cuda*.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19655854129. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2025-11-25T02:21:18Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found it was in an excellent condition.

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2025-11-25T02:39:28Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/fvdb-core/meta.yaml:

ℹ️ top-level output has some malformed specs:

In section host: pytorch pytorch=*cuda*
In section run: pytorch pytorch=*cuda*
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19656331531. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2025-11-25T02:47:24Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found it was in an excellent condition.

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2025-11-25T03:34:26Z

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19657321507. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2025-11-25T03:53:02Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/fvdb-core/meta.yaml:

ℹ️ top-level output has some malformed specs:

In section host: pytorch =*=*cuda*
In section run: pytorch =*=*cuda*
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21971138885. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

github-actions · 2025-11-25T04:38:34Z

Hi! This is the staged-recipes linter and I found some lint.

It looks like some changes were made outside the recipes/ directory. To ensure everything runs smoothly, please make sure that recipes are only added to the recipes/ directory and no other files are changed.

If these changes are intentional (and you aren't submitting a recipe), please add a maintenance label to the PR.

File-specific lints and/or hints:

.ci_support/linux64_cuda129.yaml:
- lints:
  - Do not edit files outside of the recipes/ directory.
.azure-pipelines/azure-pipelines-linux.yml:
- lints:
  - Do not edit files outside of the recipes/ directory.

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

This reverts commit a01c27e. Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

github-actions · 2025-11-25T19:30:27Z

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

swahtz · 2025-11-25T19:35:43Z

@conda-forge/help-python, ready for review!

This pytorch plugin requires CUDA 12.9. In the current 12.6 ci_support configuration, the conda environments for the build will fail to resolve and so I had to modify the ci_support config to be able to run properly which you can see running here:

https://github.com/conda-forge/staged-recipes/runs/56342507840

And I reverted that change for the current state of the PR. Unfortunately the machine it's running on seems to run out of memory partway through the build, though I can confirm the recipe runs successfully on my local machine with build-locally.py.

Thank you

swahtz · 2025-11-25T19:36:25Z

@conda-forge-admin, please ping team

conda-forge-webservices · 2025-11-25T19:36:31Z

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/staged-recipes and so here I am doing that.

github-actions · 2025-11-25T19:36:42Z

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

swahtz · 2025-11-25T19:39:32Z

@conda-forge/help-python-c, ready for review!

This pytorch plugin requires CUDA 12.9. In the current 12.6 ci_support configuration, the conda environments for the build will fail to resolve and so I had to modify the ci_support config to be able to run properly which you can see running here:

https://github.com/conda-forge/staged-recipes/runs/56342507840

And I reverted that change for the current state of the PR. Unfortunately the machine it's running on seems to run out of memory partway through the build, though I can confirm the recipe runs successfully on my local machine with build-locally.py.

Thank you

conda-forge-admin · 2026-02-13T01:32:35Z

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found some lint.

Here's what I've got...

For recipes/fvdb-core/meta.yaml:

❌ requirements: run_constrained: __cuda >= 12.8 should not contain a space between relational operator and the version, i.e. __cuda >=12.8

For recipes/fvdb-core/meta.yaml:

ℹ️ top-level output has some malformed specs:

In section host: pytorch =*=*cuda*
In section run: pytorch =*=*cuda*
In section run_constrained: __cuda >= 12.8
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21971188651. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

conda-forge-admin · 2026-02-13T01:40:46Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fvdb-core/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/fvdb-core/meta.yaml:

ℹ️ top-level output has some malformed specs:

In section host: pytorch =*=*cuda*
In section run: pytorch =*=*cuda*
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/22127823460. Examine the logs at this URL for more detail.}

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jameslamb · 2026-02-13T02:44:46Z

+
+
+setup_parallel_build_jobs
+$PYTHON -m pip install . --no-deps --no-build-isolation -vv


Suggested change

$PYTHON -m pip install . --no-deps --no-build-isolation -vv

export CMAKE_GENERATOR=Ninja

$PYTHON -m pip install \

--no-deps \

--no-build-isolation \

-vv \

-C 'skbuild.ninja.make-fallback=false' \

.

The latest build is failing like this:

-- Configuring done (68.4s) CMake Error in .cpm_cache/vulkanheaders/6fc921fffac75636a2e70c97404ed7ccbe1cfabf/CMakeLists.txt: The target named "Vulkan-Module" has C++ sources that may use modules, but modules are not supported by this generator: Unix Makefiles Modules are supported only by Ninja, Ninja Multi-Config, and Visual Studio generators for VS 17.4 and newer. See the cmake-cxxmodules(7) manual for

Let's try forcing the use of ninja.

Ha looks like you beat me to it: 5bb4a7e

I think you still might want to also set skbuild.ninja.make-fallback=false to be sure we get a loud error if ninja can't be found (instead of silently falling back to make). But not too important either way.

…en ninja isn't available Added -Wno-error=stringop-overflow to fix false positive in GCC 14 Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

… present Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jakirkham

Thanks Jonathan! Also thanks James for reviewing 🙏

Had a couple questions on the recipe. Mostly minor. And some simplifications

Think this is coming along nicely 🙂

jakirkham · 2026-02-14T01:00:07Z

+    - cuda-version {{ cuda_compiler_version }}
+    - cuda-nvcc-impl >=12.8
+    - cuda-nvrtc-dev
+    - cuda-nvtx-dev


It looks like this isn't getting detected by CMake

-- CPM: Adding package nvtx3@3.1.0 (v3.1.0-c-cpp) -- get_nvtx.cmake: Forced nvtx3_dir to CACHE: /home/conda/staged-recipes/build_artifacts/fvdb-core_1771020205707/work/build/cp312-cp312-linux_x86_64-Release/_deps/nvtx3-src/include (from CPM source)

So we may need to adjust the CMake options so it is found

Alternatively we can use the nvtx-c package where we have confirmed CMake detection works

If we need to push more changes here, we can include one of these fixes. Otherwise it is ok to handle in the feedstock

I think I'd prefer to handle it in the feedstock just because we're gearing up for a new release in early March where I can make these build changes (as well as some of the other changes to support the conda-forge build better) and not have to patch the old 0.3.0 release.

Have filed this as issue: conda-forge/fvdb-core-feedstock#3

jakirkham · 2026-02-14T01:07:32Z

+    - {{ compiler('cxx') }}
+    - {{ compiler('cuda') }}
+    - cuda-version {{ cuda_compiler_version }}
+    - cuda-command-line-tools


What do we use from here?

I believe just nvcc, I thought this was the appropriate way to pull in the CUDA compiler. I had found at some point that {{ compiler('cuda') }} wasn't enough

Yeah {{ compiler('cuda') }} should be enough for nvcc

Have filed this as issue: conda-forge/fvdb-core-feedstock#2

jakirkham · 2026-02-14T01:38:36Z

I think my most recent round of comments should help answer the "how do I ensure CUDA >= 12.8" question, and hopefully that'll mean we can see some working builds.

If we wanted to do this, we could adjust the skip to exclude CUDA versions we don't support

The reason being we treat the CUDA version as a matrix variable (like Python). So we either build or don't build for a specific CUDA version. So within any specific build it is pinned to a version. It isn't being solved for like any other dependency

Hope that makes more sense. Happy to discuss more

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jakirkham · 2026-02-14T12:01:51Z

It looks like we got through the tests! 🥳

The tests that fail reference the absence of a GPU. Is there an easy way to skip those tests?

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

swahtz · 2026-02-15T22:33:30Z

It looks like we got through the tests! 🥳

The tests that fail reference the absence of a GPU. Is there an easy way to skip those tests?

Yes this is great, thanks @jakirkham! I pushed up a change to the test script to check for the presence of GPU

However, with some of the other recipe changes, I'm now getting these overlinking errors on packaging. I believe some of the lines I removed/changed in my last commit were changes I discovered earlier I needed to resolve these overlinking errors.

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1463111&view=logs&j=317836d8-2a86-5766-e372-44e4459f9db0&t=3a0bcf2e-03de-567a-9c0c-03d6e9873a3d&l=2019

jakirkham · 2026-02-17T21:48:30Z

Thanks Jonathan! Credit goes to you and James for getting this into shape 🙏

Based on the CI overlinking error, it looks like we are linking to cudnn

  ERROR (fvdb-core,lib/python3.12/site-packages/fvdb/libfvdb.so): Needed DSO lib/libcudnn.so.9 found in ['conda-forge/linux-64::libcudnn==9.10.2.21=hf7e9902_0']
  ERROR (fvdb-core,lib/python3.12/site-packages/fvdb/libfvdb.so): .. but ['conda-forge/linux-64::libcudnn==9.10.2.21=hf7e9902_0'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

Does that sound correct? Should we be depending on cudnn? Or is this coming in accidentally?

swahtz · 2026-02-17T22:03:43Z

Thanks Jonathan! Credit goes to you and James for getting this into shape 🙏

Based on the CI overlinking error, it looks like we are linking to cudnn
  ERROR (fvdb-core,lib/python3.12/site-packages/fvdb/libfvdb.so): Needed DSO lib/libcudnn.so.9 found in ['conda-forge/linux-64::libcudnn==9.10.2.21=hf7e9902_0']
  ERROR (fvdb-core,lib/python3.12/site-packages/fvdb/libfvdb.so): .. but ['conda-forge/linux-64::libcudnn==9.10.2.21=hf7e9902_0'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
Does that sound correct? Should we be depending on cudnn? Or is this coming in accidentally?

Well @jakirkham we do use cudnn_frontend and cudnn that comes from PyTorch (which it has dynamically linked I believe), not sure if that's the issue?

jameslamb · 2026-02-17T23:22:32Z

+    - gitpython
+    - git
+    - parameterized
+


Anticipating more comments for the cudnn question, could we use a thread?

I see the following in the CMake configure logs:

-- USE_CUDNN is set to 0. Compiling without cuDNN support

But then later see cudnn_frontend pulled in via CPM:

-- CPM: Adding package cudnn_frontend@1.3.0 (v1.3.0) -- Populating cudnn_frontend -- Configuring done (0.0s) -- Generating done (0.0s) -- Build files have been written to: /home/conda/staged-recipes/build_artifacts/fvdb-core_1771202868458/work/build/cp312-cp312-linux_x86_64-Release/_deps/cudnn_frontend-subbuild [1/9] Creating directories for 'cudnn_frontend-populate' [1/9] Performing download step (git clone) for 'cudnn_frontend-populate' Cloning into 'cudnn_frontend-src'... HEAD is now at 1b0b5ea cudnn frontend v1.3 release notes. (#72) [2/9] Performing update step for 'cudnn_frontend-populate' -- Already at requested tag: v1.3.0 [3/9] No patch step for 'cudnn_frontend-populate' [5/9] No configure step for 'cudnn_frontend-populate' [6/9] No build step for 'cudnn_frontend-populate' [7/9] No install step for 'cudnn_frontend-populate' [8/9] No test step for 'cudnn_frontend-populate' [9/9] Completed 'cudnn_frontend-populate'

Either way, could the libcudnn.so dependency be coming through transitively from libtorch.so?

conda create \ --name torch-test \ --yes \ 'libtorch 2.9.1 cuda129_mkl_hf3b6726_305' source activate torch-test find ${CONDA_PREFIX} -name 'libtorch.so*' -exec ldd {} \+

... libcudnn.so.9 => /home/jlamb/miniforge3/envs/torch-test/lib/././libcudnn.so.9 (0x000078d7fe200000) ...

And if it is, shouldn't the pytorch =*=*{{ torch_proc_type }}* dependency in run: be enough to pull in libtorch and therefore libcudnn? 🤔

I will try to look into this soon.

I would have thought the same @jameslamb

cudnn_frontend is header-only afaik. But I do see that we have dynamically linked libcudnn directly:

❯ readelf -d libfvdb.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libtorch.so] 0x0000000000000001 (NEEDED) Shared library: [libc10.so] 0x0000000000000001 (NEEDED) Shared library: [libc10_cuda.so] 0x0000000000000001 (NEEDED) Shared library: [libcudnn.so.9] 0x0000000000000001 (NEEDED) Shared library: [libtorch_cpu.so] 0x0000000000000001 (NEEDED) Shared library: [libtorch_cuda.so] 0x0000000000000001 (NEEDED) Shared library: [libcudart.so.12] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]

Should I add libcudnn to reqs/run as the error message implies or should I add libcudnn-dev to reqs/host like the other CUDA libraries?

I added the requirement to the run requirements and now we're back to passing checks!

Ok great! I think it's fine for now to just take on the dependency and to investigate removing it later in the feedstock.

By the way, if you want (no pressure!) I'd be happy to join as a maintainer for this recipe if you'd like another set of hands to keep things moving.

That would be amazing, thank you! Someone who can lend a hand with knowledge in this domain would be fantastic

Ok sure, thanks! You could add me in the recipe-maintainers: section in the recipe here, or we can do it later in the feedstock, following https://conda-forge.org/docs/maintainer/updating_pkgs/#updating-the-maintainer-list

Either is fine.

Filed an issue to follow up on cuDNN: conda-forge/fvdb-core-feedstock#4

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jameslamb

We identified a couple of other things to be done in the feedstock (tuning dependencies, improving build times, covering more Python versions) but I'm happy with the current state of this. Thanks for working through all the feedback!

jakirkham · 2026-02-20T19:56:26Z

Thanks Jonathan and James! 🙏

Sounds like a plan

swahtz added 2 commits November 25, 2025 14:31

Initial fvdb-core recipe

522f654

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix some run requirements and abouts

93632a6

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix up linting issues

a1b16f8

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix syntax

0b092ba

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix a linting warning

ac0e31a

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

swahtz added 2 commits November 25, 2025 16:06

Fix typo and skip cpu builds

52933ae

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix CPU builds, referencing torchvision

8cff108

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Fix syntax issues

435544e

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

swahtz added 3 commits November 25, 2025 17:03

Attempt to fix linux_64 build

3934796

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Attempt to fix linux_64 build

f4dff09

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Update CUDA 12.6 -> 12.9

a01c27e

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

swahtz added 2 commits November 25, 2025 22:28

Fix cudnn run requirements

400ed39

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Revert "Update CUDA 12.6 -> 12.9"

31b5b82

This reverts commit a01c27e. Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

github-actions Bot added python review-requested labels Nov 25, 2025

github-actions Bot added the staged-recipes label Nov 25, 2025

Merge branch 'main' into fvdb-recipe

40757ee

swahtz added 2 commits February 13, 2026 14:37

Fix linting issue

0ac3ad8

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

revert to more complete CUDA arch list compatible with CUDA >=12.8

c09240c

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Ninja cmake generator added to build script

5bb4a7e

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jameslamb reviewed Feb 13, 2026

View reviewed changes

swahtz and others added 5 commits February 13, 2026 16:12

Add 'skbuild.ninja.make-fallback=false' to make sure we fail early wh…

faee720

…en ninja isn't available Added -Wno-error=stringop-overflow to fix false positive in GCC 14 Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Skip all except python 3.12 build to work around build timeout

115a58a

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Add tests script following cupy example for not running if GPU is not…

293053d

… present Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Merge branch 'main' into fvdb-recipe

6c2dca5

add gitpython tests dependency

416d5a5

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jakirkham reviewed Feb 14, 2026

View reviewed changes

fix git requirement

843b148

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

addressing notes

be89090

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

Merge branch 'main' into fvdb-recipe

78da6b5

jameslamb reviewed Feb 17, 2026

View reviewed changes

ad libcudnn-dev to reqs/host

7424821

Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>

jameslamb approved these changes Feb 20, 2026

View reviewed changes

jakirkham approved these changes Feb 20, 2026

View reviewed changes

jakirkham merged commit d87366e into conda-forge:main Feb 20, 2026
9 checks passed

This was referenced Feb 20, 2026

Drop cuda-command-line-tools conda-forge/fvdb-core-feedstock#2

Closed

NVTX not detected conda-forge/fvdb-core-feedstock#3

Open

Transient cuDNN dependency from PyTorch conda-forge/fvdb-core-feedstock#4

Closed



		setup_parallel_build_jobs
		$PYTHON -m pip install . --no-deps --no-build-isolation -vv

-$PYTHON -m pip install . --no-deps --no-build-isolation -vv
+export CMAKE_GENERATOR=Ninja
+$PYTHON -m pip install \
+    --no-deps \
+    --no-build-isolation \
+    -vv \
+    -C 'skbuild.ninja.make-fallback=false' \
+    .

Uh oh!

Conversation

swahtz commented Nov 25, 2025

Uh oh!

github-actions Bot commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Nov 25, 2025

Uh oh!

swahtz commented Nov 25, 2025

Uh oh!

swahtz commented Nov 25, 2025

Uh oh!

conda-forge-webservices Bot commented Nov 25, 2025

Uh oh!

github-actions Bot commented Nov 25, 2025

Uh oh!

swahtz commented Nov 25, 2025

Uh oh!

conda-forge-admin commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-admin commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakirkham left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jakirkham commented Feb 14, 2026

Uh oh!

jakirkham commented Feb 14, 2026

Uh oh!

swahtz commented Feb 15, 2026

Uh oh!

jakirkham commented Feb 17, 2026

Uh oh!

swahtz commented Feb 17, 2026

Uh oh!

jameslamb Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

conda-forge-admin commented Nov 25, 2025 •

edited

Loading

github-actions Bot commented Nov 25, 2025 •

edited

Loading

conda-forge-admin commented Feb 13, 2026 •

edited

Loading

conda-forge-admin commented Feb 13, 2026 •

edited

Loading

jameslamb Feb 17, 2026 •

edited

Loading

swahtz Feb 17, 2026 •

edited

Loading